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Analyzing and Servicing Imaging Devices 

Background of the Invention 
[0001] Imaging devices are devices that are able either to replicate or to author 
images. Such devices include printers, plotters, scanners, copiers, etc. Imaging 
devices have a means for storing information regarding attributes of the devices. 
5 Such information includes configuration settings, fault occurrences, usage history, 
levels of consumables (e.g. ink or toner), paper jams, firmware errors, hardware 
malfunctions, etc. This information is stored in "object identifiers" ("OlDs") within a 
"management information base" ("MIB") within each imaging device. The MIB 
comprises a computer memory within the imaging device. The OlDs each comprise 
10 one or more bytes of data and correspond to the status or condition of the device 
attributes. 

[0002] The computer memory of the imaging devices can be accessed externally by 
other devices, such as computer systems either connected directly to the imaging 
devices via a cable (e.g. a parallel port cable, a universal serial bus cable, etc.) or 
15 connected remotely to the imaging devices via a network (e.g. a local area network, a 
wide area network, the Internet, etc.). Thus, the MIB of each imaging device can be 
electronically interrogated to discover or read the stored information concerning the 
imaging device attributes. 

[0003] For a given imaging device, if it is known which device attribute corresponds 
20 to each OID, then a complete status or condition of the imaging device can be 

formulated by reading the OlDs from the MIB of the imaging device. Therefore, if a 
problem occurs in the imaging device, the problem can be diagnosed by reading the 
MIB data from the imaging device and analyzing the received data for a match with 
existing data. An appropriate solution to the problem can then be implemented, such 
25 as ordering a service call to the imaging device to refill consumables, replace 
defective components, etc. 

[0004] The ability to analyze the MIB data to determine the condition of the imaging 
device requires xact knowl dg of the MIB structure of the imaging device. In other 
words, the meaning of each OID within the MIB must be known. Therefore, when an 



imaging device is encountered for which the MIB structure is not completely known, 
the MIB must first be deciphered. The imaging device with "unknown" MIB portions 
may be encountered, for example, in a situation in which a servicing contract between 
two parties obligates one of the parties to service the other party's imaging devices, 
5 regardless of the manufacturer of the imaging devices. Most imaging device 

manufacturers make at least some of the OlDs, such as those specifying the vendor 
and model of the imaging device, publicly available. To discover other OlDs in the 
MIB, the imaging device is subjected, within a laboratory setting, to a wide variety of 
conditions or situations related to the device attributes. The MIB is read and analyzed 

10 for each situation. For example, if the imaging device is a printer, then the printer can 
be subjected to different situations in which paper has been inserted therein and 
removed therefrom. Any differences in any of the OlDs under the different situations 
indicate the OlDs that are related to the presence and absence of the paper. 
[0005] After extensive trial-and-error testing of the imaging device, the OlDs related 

15 to the tested attributes are identified. This information is used to diagnose problems 
or record the status of imaging devices of the same type used outside the laboratory 
in real-world situations. Without this information, when presented with a 
malfunctioning imaging device, a service technician or a call center agent would have 
to iterate through several possible solutions until the imaging device worked. The 

20 testing procedure to decipher the MIB and its OlDs, however, is very time-consuming, 
labor-intensive and costly. Additionally, the testing procedure must be repeated for 
every available imaging device, of which there are hundreds currently on the market. 

Summary of the Invention 
[0006] According to a particular embodiment of the present invention, a method of 
25 analyzing and servicing an imaging device comprises receiving data from the imaging 
device; determining whether the received data matches existing data; upon 
determining that the received data matches the existing data, selecting an action to be 
taken that correlates with the matched existing data; and adding the received data to 
the existing data. 

30 [0007] According to another embodiment of the present invention, a method of 
analyzing and servicing imaging devices comprises, for each imaging device of at 
least a portion of the imaging devices, periodically reading object identifiers from the 
imaging device, calculating a quantifier value from the object identifiers and recording 
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the quantifier value; and for at least one of the imaging devices: taking action in 
response to a condition of the imaging device; recording the condition and the action 
taken; and correlating the condition and action taken with a most recent quantifier 
value for the imaging device recorded prior to taking the action. 
5 [0008] Additionally, according to yet another embodiment, an imaging device 

service system comprises an object identifier data input, a quantifier value calculator, 
a database, a quantifier value comparator and a workflow action initiator. The 
quantifier value calculator is connected to the object identifier data input to receive 
object identifier data from which a quantifier value is calculated. The database stores 

10 quantifier data and action data. The quantifier value comparator is connected to the 
quantifier value calculator to receive the quantifier value and to the database to 
receive the quantifier data. The quantifier value comparator compares the quantifier 
value with the quantifier data and generates a comparison result. The workflow action 
initiator is connected to the quantifier value comparator to receive the comparison 

15 result and to the database to receive the action data. The workflow action initiator 
initiates a workflow action according to the comparison result and the action data. 

Brief Description of the Drawings 
[0009] Fig. 1 is a block diagram of an imaging device service system incorporating 
an embodiment of the present invention. 
20 [0010] Fig. 2 is a flow chart of an embodiment of a procedure for acquiring imaging 
device data from an enterprise facility incorporated in the imaging device service 
system shown in Fig. 1 . 

[0011] Fig. 3 is a functional block diagram of an embodiment of an imaging device 
service center incorporated in the imaging device service system shown in Fig. 1 . 

25 [0012] Fig. 4 is an embodiment of a table of a portion of an embodiment of a 
database incorporated in the imaging device service center shown in Fig. 3. 
[0013] Fig. 5 is a flow chart of an embodiment of a procedure for handling the 
imaging device data acquired by the procedure shown in Fig. 2. 
[0014] Fig. 6 is a flow chart of an embodiment of a procedure for handling feedback 

30 in the imaging device service center shown in Fig. 3. 

[0015] Fig. 7 is a flow chart of an embodiment of a procedure for generating an 
action order in the imaging device service center shown in Fig. 3. 
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Detailed Description 

[0016] An imaging device service system 100 ("service system") generally includes 
an enterprise facility 102 and an imaging device service center 104 ("service center"), 
as shown in Fig. 1. The enterprise facility 102 and the service center 104 are 
5 connected via a network 106, such as a wide area network, a phone line, the Internet, 
etc., so that the service center 104 can receive imaging device data from the 
enterprise facility, as described below. 

[0017] The enterprise facility 102 generally includes several imaging devices 108 
and computers 110 connected either directly together (e.g. at 1 12) or by another 

10 network 114, such as a local area network, a Fibre Channel network, etc. The 

imaging devices 108 generally include any device that is able to replicate, or author 
images, such as printers, plotters, scanners, copiers, etc. The computers 110 
generally include personal computers, workstations, mini computers, mainframe 
computers, etc. The imaging devices 108 generally serve any imaging requirements 

15 of the computers 110. For example, among other imaging functions, the imaging 
devices 108 may print or scan documents for the computers 110. 
[0018] Although an embodiment of the invention is described with reference to the 
enterprise facility 102 having multiple imaging devices 108 and multiple computers 
110, it is understood that the invention is not so limited. Rather, the invention may be 

20 used in any situation having any number of imaging devices 108 and computers 110, 
even one of each. 

[0019] The service center 104 generally includes at least one computer 116. As 
described below, the computer 116 receives and analyzes the imaging device data 
and determines servicing requirements for the imaging devices 108. The service 
25 center 1 04, thus, coordinates imaging device servicing operations for the enterprise 
facility 102, typically under a servicing contract between an owner of the enterprise 
facility 102 and an owner of the service center 104. 

[0020] At least one of the computers 1 10 in the enterprise facility 102 serves as a 
"service appliance" 1 10\ The service appliance 110' connects to the computer 1 16 in 
30 the service center 104 via the network 106. The service appliance 110' gathers the 

imaging device data from the imaging devices 108 and sends the imaging device data 
to the computer 116. 

[0021] The imaging device data gathered by the service appliance 110' includes at 
least a portion, if not all, of the management information bas ("MIB") of each imaging 



device 108. To gather the imaging device data, therefore, the service appliance 110' 
periodically reads the object identifiers ("OlDs") from the MIB of each imaging device 
108. The data read comprises the imaging device data. 

[0022] For an imaging device 108 for which the structure of the MIB is known, each 
5 OID can be specifically addressed as needed. The service appliance 110' sends read 
messages to IP addresses according to a communication protocol (e.g. SNMP, IEEE 
1284, Firewire, parallel port standards, Universal Serial Bus, etc.) requesting the data 
from each desired OID. For an imaging device 108 for which the MIB structure is 
unknown or only partially known, the service appliance 110' preferably reads all of the 

10 OlDs, instead of only selected ones. 

[0023] An exemplary procedure 1 1 8 for the service appliance 1 1 0' to acquire the 
imaging device data from the imaging devices 108 in the enterprise facility 102 is 
shown in Fig. 2. Upon starting (at 120), the imaging devices 108 on the network 114 
are "discovered" (at 122). Some of the imaging devices 108 may already be known to 

15 the service appliance 110'. In which case, it is preferable to poll the known imaging 
devices 108 to determine whether they are still active or still connected to the network 
1 14 at a given network address. For those imaging devices 108 that are not known to 
be on the network 114, the service appliance 110' preferably polls all network nodes 
to determine which network nodes have imaging devices 108 connected thereto. 

20 Alternatively, the service appliance 110' may also "snoop* network communications 
for any communications directed to unknown imaging devices 108, thereby 
discovering these imaging devices 108 when they are used. The service appliance 
110' may also preferably periodically repeat this discovery action to determine 
whether any imaging devices 108 have been added to or removed from the network 

25 114. 

[0024] For each imaging device 108, any OlDs that are public or otherwise already 
known or defined within the service system 100 are preferably read (at 124) to acquire 
imaging device data for which the meaning is known. This data can be used to 
diagnose specific conditions or problems for the imaging devices 108. The remaining 
30 data is generally proprietary to the imaging device manufacturer and is read (at 126) 
generally without regard to specific OlDs. Since the MIB structure is at least partially 
unknown, the service appliance 110' preferably uses "get next" and "get block" 
commands, such as are availabl under the SNMP protocol, to acquire unknown 
succeeding portions of the data. These commands do not require an exact 



knowledge of whatever data structure is employed in the MIB, since the imaging 
device 108 will respond by merely returning the next portion of the data in the memory 
of the imaging device 108. The s rvice appliance 110' ends the proprietary data 
gathering (at 126) preferably after no additional data is returned by a target imaging 
5 device 108 in response to such commands. In other words, the imaging device 108 
eventually responds that there isn't anything "next." This technique for data gathering 
is commonly referred to as "MIB walking," since the data is accessed by "stepping" 
through the MIB structure. 

[0025] The data in the MIB is stored in a type of "tree" structure having a variety of 
10 levels. Each level of the MIB tree "branches" out from a higher level of the MIB tree. 
The highest level is generally referred to as the "root" and is typically designated by 
OID 1 . The root of the MIB typically identifies the type of the imaging device, such as 
a printer, a scanner, a copier, etc. The next level in the MIB tree typically branches 
out to include more than one OID that refer generally to categories of various portions 
15 of the imaging device 108. For a printer, such OlDs may refer to accessories (e.g. 

OID 1.0), paper (e.g. OID 1.1), ink (e.g. OID 1.2), other consumables (e.g. OID 1.4), 
etc. 

[0026] The OlDs may not be numbered consecutively, and each branch of the MIB 
tree may not have the same number of levels. The MIB walking technique, however, 
20 manages to obtain all of the imaging device data without such knowledge regarding 

the MIB structure of the imaging devices 108. By "walking" through the MIB tree, each 
of the OlDs is read and the data obtained. 

[0027] Many of the lowest level OlDs in the branches of the MIB tree relate to 
specific sensors within the imaging device 108. Such sensors may detect, for 
25 example, an empty paper tray, an empty magenta toner cartridge, an open 

compartment panel, etc. The related OlDs, thus, indicate the state of the sensors, 
and thereby, various conditions of the imaging device 108. 

[0028] The MIB walking technique, however, is generally performed without regard 
to the meaning of any of the OlDs. In the prior art, described above, only those OlDs 
30 for which the meaning was known were read, since unknown OlDs were of no use. It 
was thus necessary to know the tree structure to read specific OlDs. In the present 
case, on the other hand, it is preferable to read the entire MIB indiscriminately, since it 
may not be known which OlDs are relevant to any given situation. 
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[0029] The data gathering (at 1 24 and 126) is repeated for each imaging device 1 08 
until the data for the last imaging device 108, as determined at 128, has been 
acquired. The data thus obtained is transferred (at 1 30) by the service appliance 110' 
to the computer 1 16 at the service center 104. The data acquisition procedure 118 
5 either ends (at 1 32) or repeats periodically. 

[0030] An alternative, which can be done instead of or in addition to the MIB walking 
technique described for the data acquisition procedure 1 18, is to monitor network 
traffic with a "sniffer." The sniffer (e.g. one of the computers 1 1 0, preferably the 
service appliance 1 10') unobtrusively reads messages that are sent over the network 

10 1 14. In this case, the sniffer is monitoring the messages for communications related 
to the imaging devices 1 08. Of particular interest are messages from the imaging 
devices 108, since most imaging devices 108 are capable of responding to a 
requested imaging function, such as a print job, with various types of error messages, 
such as an "out-of-paper" or "out-of-toner" message. A utility (provided by the 

1 5 manufacturer of the imaging device 1 08 and operating on the computer 110 that 

requested the imaging function) receives the error message and typically alerts a user 
to the problem encountered. The user may be able to remedy the problem, such as 
by adding paper to the imaging device 108 or changing a toner cartridge therein. In 
many instances, however, it may not be the user's job to service or repair any of the 

20 imaging devices 108. Instead, it is typically the responsibility of the service center 104 
to alert a service technician to service and repair the imaging devices 108. The 
sniffer, therefore, causes the service appliance 1 10' to send to the computer 116 part 
or all of the message that was generated by the imaging device 108. The computer 
116 preferably handles, or analyzes, this message in a manner similar to that with 

25 which it handles the imaging device data, as described below, to diagnose any 
problems with the imaging devices 108 that need servicing. 

[0031] Although it is preferable to discover any imaging device problems through 
periodic reading of the MIB before any requested imaging device functions are 
affected, it is not always possible or practical to do so. The "sniffer technique," 
30 therefore, enables the problem to be discovered soon after it affects a requested 
imaging device function. 

[0032] The service system 100 has the ability to incorporate the trial-and-error 
testing procedure described in the background without the need for a laboratory 
setting, particularly when the sniffer technique is employed. In this case, one or more 



of the imaging devices 108 within the ent rprise facility 102 may be intentionally 
subjected to various conditions resulting in messages being sent from the imaging 
devices 108 upon encountering an imaging device function that cannot be processed. 
The sniffer will automatically pass the messages on to the computer 1 16 for analysis, 
5 the results of which can be correlated with the conditions to which the imaging devices 
108 were intentionally subjected. 

[0033] The service center 104 performs a variety of functions, as illustrated by 
functional blocks shown in Fig. 3, operating on the computer 116 (Fig. 1). Generally, 
the service center 104 receives the imaging device data (at MIB/OID Data Input 134) 

10 and condition/action feedback data (at Feedback Data Input 136) and analyzes this 
data to build a database 138 of imaging device data correlated with feedback data. 
The feedback data generally comprises the conditions that some of the imaging 
devices 108 have been subjected to, either intentionally during device testing or 
unintentionally during a normal course of operation of the imaging devices 108, and 

15 the actions taken to correct the conditions. The feedback data may preferably be 
generated by service technicians who have serviced the imaging devices 108 and 
reported the problems and solutions they have encountered in the field. Additionally, 
the service center 104 receives the imaging device data (at MIB/OID Data Input 134) 
and analyzes this data in combination with the database 138 of previously generated 

20 imaging device data and correlated condition/action feedback data to generate action 
orders (at Action Output 140) for servicing the imaging devices 108. 
[0034] The functional blocks shown are exemplary only. Therefore, the general 
analyzing and servicing functions of the service system 100 (Fig. 1) may be 
implemented in any appropriate manner to perform part or all of the functions 

25 described with reference to the functional blocks. 

[0035] Generally, the service center 104 preferably includes a device identification 
functional block ("device identifier*) 142, a database generator functional block 
("database generator") 144, a MIB/OID Analysis functional block ("MIB analyzer") 146 
and a workflow action analysis/initiation functional block ("workflow action initiator) 

30 148. The device identifier 142 generally receives the imaging device data (at 134) 
and attempts to identify the "type" of imaging device 108 from which the imaging 
device data was read. The database generator 144 generally uses the imaging 
device data, the feedback data and the results of calculations and analyses performed 
within the service center 104 to generate the database 138. The MIB analyzer 146 



generally calculates "quantifier values" (described below) from the imaging device 
data and analyses the imaging device data and the quantifier values in combination 
with data read from the database 138. Th workflow action initiator 148 generally 
determines an action to be taken in response to the results of the analyses performed 
5 by the MIB analyzer 146 and in accordance with data read from the database 138. 
[0036] The device identifier 1 42 generally attempts to identify the type of the 
imaging device 108 by searching the database 138 for a matching device type. The 
"type" information is usually part of the information that imaging device manufacturers 
make public, so this information can be entered into the database 138 manually when 
10 the first imaging device 108 of each type is placed on the network 1 14 (Fig. 1 ). The 
type information may also be defined in the root level of the MIB, so the type may 
potentially be discovered by analyzing the imaging device data without recourse to the 
database 1 38. 

[0037] If the device identifier 142 cannot identify the type of imaging device 108 
1 5 involved or if there is no existing entry for the type in the database 1 38, then the type 
of imaging device 108 may not have been previously encountered by the service 
center 104 (Fig. 1). In this case, it is likely not possible to analyze the imaging device 
data to generate an action order (at Action Output 140) for servicing the imaging 
device 108 from which the imaging device data was read. The imaging device data 
20 can, however, be used to build, or add to, the database 1 38 with an initial entry for a 
new type, but with no feedback data yet correlated therewith. The device identifier 
142, thus, passes the imaging device data to the database generator 144, so the 
imaging device data 144 can be added to the database 138. The device identifier 142 
also preferably passes the imaging device data to the MIB analyzer 146 for calculation 
25 of the quantifier values, which are also to be added to the database 138, so the 
quantifier values can potentially be used for future analyses. 

[0038] If the device identifier 142 identifies the type of imaging device 108 involved, 
then the device identifier 142 passes the imaging device data and the type information 
to the MIB analyzer 146. 
30 [0039] The MIB analyzer 146 generally includes a known OID match functional 
block ("OID matcher") 150, a data section functional block ("data sectioner") 152, a 
quantifier value(s) calculation functional block ("quantifier calculator") 154 and a 
quantifier value comparison functional block ("quantifier comparator") 156 and a 
probability value calculation functional block ("probability calculator") 157. The OID 



matcher 150 generally attempts to determine whether any data for identifiable, or 
known, OlDs in the imaging d vice data match any data patterns indicating a problem 
with, or condition of, the imaging device 108. The data sectioner 152 generally 
partitions, or divides, the imaging device data into appropriate sections. The quantifier 
5 calculator 154 generally calculates the one or more quantifier values from the imaging 
device data as a whole and/or from the sections thereof. The quantifier comparator 
1 56 generally compares the quantifier values to previously calculated quantifier values 
for the same type of imaging device to potentially identify a condition of the imaging 
device 108. The probability caiculator157 generally determines a probability value 
10 indicating a degree of confidence in whether the identified condition of the imaging 
device 108 is correct. 

[0040] The OID matcher 150 attempts to match the data for any known OlDs 
generally by using pattern-matching techniques. Thus, the OID matcher 150 
accesses the device type in the database 138 to determine whether any of the OlDs 

15 for the type are known. Such OlDs are generally those that are made public by the 

imaging device manufacturer or that may have been identified using the trial-and-error 
testing procedure described above. If the type of the imaging device was not 
identified by the device identifier 142, then there likely cannot be an OID comparison, 
so the OID matcher 150 is preferably bypassed, and the imaging device data is 

20 preferably passed to the data sectioner 152. On the other hand, if the type is known 
and if any of the OlDs are determined to be known, then any known patterns for the 
OID data that may indicate particular conditions of the imaging device 108 are read 
from the database 1 38 and compared to the pattern of ones and zeros for the known 
OID portion of the received imaging device data. It is thus determined whether there 

25 is a match between the known pattern and the received data. If there is no match, 
then the imaging device data is passed to the data sectioner 152 for further 
processing. On the other hand, if there is a match, then the type information and the 
match result (and possibly also the imaging device data) are transferred to the 
workflow action initiator 1 48 to determine an appropriate response to the match. For 

30 example, it may be known that a particular pattern in a given OID for a printer 

indicates that the printer has a fuser that is operating too hot. If the pattern is matched 
in the appropriate portion of the received imaging device data, then the workflow 
action initiator 148 will be alerted to issue an appropriate action order to remedy this 
condition, such as sending a service technician to replace the fuser. 

10 



[0041] The data sectioner 152 preferably partitions the imaging device data into 
sections, so that the following quantifier value analysis (i.e. calculation and 
comparison) can be performed on the sections of the imaging device data, as well as 
on the imaging device data as a whole. The number of sections and the size of each 
5 preferably depend on the device type and are defined by a partitioning model for the 
type. The partitioning model indicates appropriate points in the imaging device data 
where the boundaries of the sections are to be drawn. For example, it may be known 
for a printer that a particular block of the imaging device data refers to various 
conditions related to paper and that another block is related to toner, so it may be 
10 advantageous to have the imaging device data partitioned along these blocks when 
performing the following quantifier value analysis. Furthermore, the quantifier value 
analysis can use pattern-matching techniques when there is more than one quantifier 
value. 

[0042] The partitioning model is preferably stored in the database 138 under the 
15 device type. Thus, the data sectioner 152 preferably reads the partitioning model from 
the database 1 38 under the device type and partitions the imaging device data 
accordingly. If the type is not known, then there may not be a partitioning model, so 
the imaging device data may be passed to the quantifier calculator 154 without 
partitioning. Alternatively, there may be a "default" partitioning model (e.g. N almost- 
20 equal-sections) to be used when the type is not known or when no model is specified. 
Additionally, there may be situations in which it is not advantageous to perform the 
following quantifier value analysis on sections of the imaging device data, so the data 
sectioner 152 is preferably an optional function. 

[0043] The quantifier calculator 154 quantifies the overall imaging device data 
25 and/or the sections thereof as the quantifier values according to a bit-by-bit 

quantification algorithm. The quantifier calculator 1 54 preferably converts each unit, 
or character, of the imaging device data or sections thereof into its hexadecimal or 
ASCII equivalent and sums the individual values to calculate the quantifier values. 
Alternatively, the quantifier values may preferably be calculated by summing the 
30 imaging device data or sections thereof on a byte-by-byte or word-by-word basis. The 
resulting quantifier values are generally a single byte of data or word of data of any 
appropriate bit length. The quantifier values are provided to the quantifier comparator 
156 for analysis and to the database generator 144 for storage in the database 1 38. 
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[0044] The quantifier values are generally indicative of the conditions that may occur 
to the imaging d vices 1 08 (Fig. 1 ), because the quantifier values are usually different 
for each condition. It is possible, however, for two different sets of MIB data from the 
same, or same type of, imaging device 108 to result in the same quantifier value. In 
5 other words, the same quantifier value may be related to two or more different 

conditions. Additionally, it is possible for two or more different quantifier values to 
relate to the same condition experienced by the same imaging device 108 at different 
times or by different imaging devices 108 of the same type. This situation can occur 
because, although the OID that relates to a particular condition is likely to be the same 
10 each time the condition occurs, one or more of the other OlDs in the MIB may be 
different at different occurrences of the same condition, since they may not be 
controlled by that condition. Therefore, the quantifier values are not necessarily 
absolute indicators of individual conditions. 

[0045] The uncertainty in the meaning of a specific quantifier value is preferably 
1 5 compensated for primarily in two ways. First, specific conditions of the imaging 

devices 108 are allowed to be correlated with multiple quantifier values and/or ranges 
of quantifier values within the database 138. Second, the probability values are 
preferably determined based on how well the current MIB data matches previous MIB 
data from which the same or similar quantifier values (or within a range thereof) were 
20 calculated. Alternatively, the probability values may be associated with previously 
occurring quantifier values or ranges of quantifier values. The probability values 
preferably indicate the probability of a particular condition having occurred to one of 
the imaging devices 108 when a specific quantifier value equaling one of the 
previously occurring quantifier values or falling within one of the ranges of quantifier 
25 values has been calculated from the imaging device data read from that imaging 

device 108. Thus, it is not necessary to know the exact data for a particular condition 
for the imaging devices 108. Instead, the probability value indicates the most likely 
condition(s). 

[0046] When it receives the quantifier values, the database generator 144 stores the 
30 quantifier values in the database 138 under the type of the imaging device 108 

associated with the quantifier values as determined by the device identifier 142, as 
described above. The database generator 144 also uses the quantifier values as 
indexes for the associated imaging device data, which is also stored in the database 
138 under the typ of the imaging device 108. When the feedback data is received at 



136, the database generator 144 generally retrieves the most recently received 
quantifier values from the database 138 and corr lates the condition and the action 
taken, according to th feedback data, with the retrieved quantifier values. The 
database generator 144 formats this information and stores it in the database 138. 
5 [0047] When the same condition is reported in the feedback data more than once 

and correlated with different quantifier values, then a range of quantifier values can be 
established between the quantifier values and correlated with that condition. A range 
can also be established as an appropriate +/- tolerance "window" surrounding one or 
more quantifier values. When a new quantifier value falls within the range of quantifier 

10 values, then the service center 104 (Fig. 1) can respond even though the exact 

quantifier value may never before have been encountered. In this manner, the service 
center 104 may be more responsive or reactive to the received imaging device data 
than it would be if it relied solely on exact matches for the quantifier values. 
[0048] An example of a database entry having quantifier value ranges and 

15 correlated conditions and actions taken is shown in a table 158 in Fig. 4. The table 
158 preferably forms part of the information stored in the database 1 38 for an 
exemplary imaging device 108 referred to as "Printer X." Several quantifier value 
ranges 160-168 have been established. The size of the quantifier value ranges 160- 
168 may vary. Each quantifier value range 160-168 has been correlated with a 

20 matching condition 170-178 and matching action 180-188. For some cases, a 
quantifier value may fall within a range (e.g. 166) matching a normal operating 
condition (e.g. 176) or requiring no action (e.g. 186). Some quantifier value ranges 
(e.g. 160 and 162) may overlap, so a calculated quantifier value may fall within both 
ranges 160 and 162. A higher probability value may be calculated for one of the 

25 ranges, or for different portions of the ranges or for individual quantifier values, due to 
the number of times one of the matching conditions 170 has occurred compared to the 
other matching condition 172. 

[0049] When the quantifier comparator 1 56 receives a calculated quantifier value for 
an imaging device 108 of the same type as Printer X, the quantifier comparator 156 
30 reads the information shown in table 158 from the database 138. The quantifier 

comparator 156 compares the quantifier value with the quantifier value ranges 160- 
168 to determine whether the quantifier value falls within any of the quantifier value 
ranges 1 60-1 68. If the quantifier value does not fall within any of th quantifier value 
ranges 160-168, then the quantifier value either has never before been encountered 



or has not yet been correlated with a condition or action. In either case, there likely is 
no action to be taken in response to the quantifier value. The quantifier value may 
also merely relate to a "normal operation" condition and not require any action. 
Nevertheless, the comparison result is preferably reported to the database generator 
5 144 to track the quantifier value as "uncorrected" until it can be correlated with a 
particular condition. If the quantifier value falls within, or matches, any of the 
quantifier value ranges 160-168, then the comparison result is reported to the 
workflow action initiator 148 to determine the action, if any, that needs to be taken in 
response to the quantifier value match. The comparison result is also reported to the 

10 probability calculator! 57 in order to calculate the probability value, as described 
below. The comparison result is also reported to the database generator 144 to 
further build the database 138 to track the number of times a calculated quantifier 
value has matched the quantifier value ranges 160-168 and the correlated conditions 
170-178. Such information, when further correlated with additional feedback data may 

1 5 affect the probability values. 

[0050] When the probability calculator 157 receives the quantifier comparison 
results, the probability calculator 157 preferably reads from the database 138 
previously stored imaging device data, or sections thereof, that was indexed to the 
matching quantifier value or quantifier value range. The probability calculator 1 57 

20 preferably uses pattern recognition algorithms to determine how closely the current 
imaging device data matches the previously stored imaging device data. The 
probability value is, thus, preferably related to the closeness of this match. 
Alternatively, after feedback data has shown that a certain percentage of the time the 
imaging devices 108 (Fig. 1) have experienced a particular failure when the quantifier 

25 values have fallen within a particular quantifier value range (e.g. 160), then the 

probability value may be the same percentage that the imaging device 108 has had 
the same failure the next time the quantifier value falls within the quantifier value 
range 160. 

[0051] The workflow action initiator 148 receives the results of any OID matches 
30 from the OID matcher 150, the results of the quantifier value comparison from the 
quantifier comparator 156 and the results of the probability calculation from the 
probability calculator 157. The workflow action initiator 148 generates at 140 an order 
for an appropriate action to be taken. The workflow action initiator 148 queries the 
database 138 for the appropriate action based on the type of th imaging device 108 

14 



and the quantifier value and OID comparison results. In the case of an OID match, 
the determination of the action is straightforward according to the condition indicated 
by the relevant OID. In the case of any quantifier value matches, the action is also 
relatively straightforward due to confidence that can be developed in the quantifier 
5 value analysis and the probability values. 

[0052] Since an initial correlation of a condition and action with a quantifier value or 
range is based on only one instance, the confidence in using this information to 
produce an action order may be relatively low. Over time, however, as more data is 
generated and shows agreement, confidence increases in the probability value and in 

10 the correlation of the quantifier value with the condition and action. Therefore, there is 
preferably a discovery/learning phase during which the database 138 is built up while 
the service center 104 is operating to service the imaging devices 108. During this 
time, the reliability of the quantifier values to correctly identify the conditions of the 
imaging devices 108 is tested by having the MIB analyzer 146 perform its analysis 

15 without having the workflow action initiator 148 output any actual action orders. 
Instead, the results of the quantifier value analysis are compared to feedback 
generated by the service technicians servicing the imaging devices 108 to determine 
how well the analysis agrees with the actual conditions encountered and resolved by 
the service technicians. With each new feedback result, the quantifier value analysis 

20 is made more reliable. Eventually, confidence becomes reasonably high, and the MIB 
analyzer 146 may be used to issue action orders in response to the quantifier value 
analysis. Eventually, the database 138 will incorporate almost every possible 
condition and action for each imaging device 108. Significant changes in the 
database 138 will thus become fewer and further between, until a new imaging device 

25 1 08 of a new type is added to the enterprise facility 1 02. The learning phase will then 
begin for the new imaging device type. 

[0053] It may take a while to assemble all of the quantifier value data for all 
conditions that could occur for each type of imaging device 108. However, it is 
acceptable to start using the accumulated data to perform the quantifier value analysis 
30 on the imaging device data before all of the possible data has been assembled. 

[0054] An exemplary procedure 190 for the service center 104 (Figs. 1 and 3) to 
analyze the imaging device data is shown in Fig. 5. Upon starting (at 192), the service 
center 104 receives (at 194) a batch of imaging device data at MIB/OID Data Input 
134 (Fig. 3). The imaging device data may be the MIB data from one, several or all of 



the imaging devices 108. If from more than one imaging device 108, the imaging 
device data for each imaging device 108 is separated at 196. For the first imaging 
device 108, the device identifier 142 (Fig. 3) identifies (at 198) the imaging device 108, 
or its type, as described above. At 200, the OID matcher 150 determines whether the 
5 imaging device type includes any known OlDs that have a pattern matching any 

corresponding portion of the imaging device data, thereby indicating a condition that 
may need servicing. If not, then the data sectioner 152 partitions (at 202) the imaging 
device data, if necessary, prior to the quantifier value calculation and analysis, 
described above. On the other hand, if the corresponding portion of the imaging 

10 device data matches any known OID data pattern, as determined at 200, then the 

match result is transferred (at 204) to the workflow action initiator 148 to determine an 
appropriate response to the match. Since it is possible for there to be a quantifier 
value match as well as an OID match indicating more than one action to take to 
service the imaging device 108, it is preferable to continue with the quantifier value 

15 analysis, as shown by the flow chart in Fig. 5. Thus, the workflow action initiator 148 
preferably does not begin to determine the appropriate action to take until the 
quantifier value analysis is done, so that all possible conditions of the imaging device 
108 may be taken into consideration. However, in an alternative, the quantifier value 
analysis may be bypassed whenever there is an OID match, thereby assuming that 

20 the OID match produces a more reliable result, but this alternative may miss any 
conditions that are not indicated by known OlDs. 

[0055] The quantifier calculator 154 quantifies (at 206) the imaging device data by 
calculating the quantifier value(s), as described above, for the sections (if any) of the 
imaging device data and/or for the overall imaging device data. If there is not yet any 

25 quantifier value data in the database 138 (Fig. 3) for the type of the imaging device 

108, as determined at 208, then the quantifier value analysis cannot be performed, but 
the quantifier value(s) calculated at 206 can be added (at 210) to the database 138 by 
transferring the quantifier value(s) to the database generator 144 (Fig. 3) for indexing 
to the imaging device data. On the other hand, if there is any quantifier value data 

30 available for performing the quantifier value analysis on the relevant type of imaging 
device 108, as determined at 208, then the quantifier comparator 156 compares (at 
212) the quantifier value(s) calculated at 206 with the quantifier value data, such as 
the quantifier value ranges 160-168 (Fig. 4), read from th database 138. If there is 
no match (at 212) between the calculated quantifier value(s) and the quantifier value 



data, then the calculated quantifier value(s) can still be added (at 210) to the database 
1 38 for future analyses. On the other hand, if there is a match (at 212), then the 
probability value is calculated at 213. The match result and probability value are 
transferred (at 214) to the workflow action initiator 148 to determine an appropriate 
5 response to the match. The calculated quantifier value(s) are still preferably added (at 
210) to the database 138 for future analyses, but the match results at 212 may also be 
taken into consideration in building the database 138. It is then determined (at 216) 
whether the last imaging device 108 for which imaging device data was received at 
194 has been processed. If not, then the procedure 190 continues with identifying the 
10 next imaging device 108 at 198 and so forth. When all of the imaging devices 108 for 
which imaging device data was received at 194 have been processed, as determined 
at 216, the procedure 190 either ends at 218, as shown, or repeats for another batch 
of imaging device data. 

[0056] An exemplary procedure 220 for the service center 104 (Figs. 1 and 3) to 

1 5 incorporate into the database 1 38 the condition/action feedback data received at 1 36 
(Fig. 3) is shown in Fig. 6. Upon starting (at 222), the service center 104 waits (at 
224) until it receives the condition/action feedback data. This feedback data may 
include a service code reported by a service technician who serviced at least one of 
the imaging devices 108. The service code may indicate the condition of the imaging 

20 device 1 08 and the action taken to remedy the condition. The feedback data also 

preferably includes any appropriate identification for the imaging device 108 that was 
serviced. The imaging device 108 is, thus, identified at 226. Using the identification 
of the imaging device 108, the most recent quantifier value data for the imaging device 
1 08 is read (at 228) from the database 1 38. Alternatively, if the feedback data 

25 includes "time" information reported for the occurrence of the condition, then the 

quantifier value data immediately preceding and/or following the time of the condition 
occurrence is read from the database 1 38. The condition and action taken are 
correlated (at 230) with the quantifier value data. The correlated quantifier value data, 
condition and action taken are added (at 232) to the database 138 under the type of 

30 imaging device. If there are previous database entries for the same or similar 

condition and or action taken correlated with previous quantifier value data, then the 
quantifier value data for the current feedback data is combined with the previous 
quantifier value data to further build (at 232) the database 138 by forming or adjusting 
the relevant quantifier value ranges (e.g. 160-168, Fig. 4) for the condition and action 



taken and by adjusting the probability values associated th rewith. The procedure 
220 either ends (at 234), as shown, or returns to wait for the next feedback data at 
224. 

[0057] An exemplary procedure 236 for the workflow action initiator 148 (Fig. 3) to 
5 generate the action orders at the Action Output 140 is shown in Fig. 7. Upon starting 
(at 238), the procedure 236 waits (at 240) until it has received all of the match results 
from both the OID matcher 150 and the quantifier comparator 156. Alternatively, the 
MIB analyzer 146 retains the match results until all of the match results have been 
assembled and then transfers all of the match results at once to the workflow action 

10 initiator 148. The imaging device 108 is identified at 242, so the workflow action 

initiator 148 will be able to read the appropriate action data from the database 138. If 
there is an OID match, as determined at 244, then the corresponding action to be 
taken is read (at 246) from the database 138. If there is a quantifier value match, as 
determined at 248, then the corresponding action to be taken (e.g. 180-188, Fig. 4) is 

15 read (at 250) from the database 138. One or more "workflow messages" are 

assembled at 252. The workflow messages indicate the action(s) to be taken to 
remedy the condition(s) of the imaging device 108. For example, if the imaging device 
108 needs a fuser replacement, then one workflow message may be sent (at 254) to a 
fuser supplier with an action order for sending a new fuser for the imaging device 108, 

20 and another workflow message may be sent (at 254) to a service technician to 

schedule a service trip to the enterprise facility 102 to coincide with the arrival of the 
new fuser. The procedure 236 either ends at 256, as shown, or repeats. 
[0058] The quantifier values and the associated probability values enable the 
service center 104 to analyze relatively large MIBs for many imaging devices 108 and 

25 build the database 138 "on the fly." In other words, instead of having to perform an 
exhaustive laboratory analysis to discover the complete description of the MIB 
structure and the meaning of each of the OlDs for each imaging device 108 before 
making use of this information, the service center 104 can begin service operations by 
responding to service calls from the enterprise facility 102 (Fig. 1 ) while building the 

30 database 138. The service center 104, thus, avoids high start-up costs associated 
with prior art service centers. Additionally, although the service technicians may 
initially have to take extra time to service some of the imaging devices 108, the 
average service time and the number of service trips to th enterprise facility 1 02 are 
eventually reduced significantly, since the quantifier value analysis becomes more 



reliable over time. Thus, as the database 138 continues to be built, the service center 
104 will be able to respond more quickly and efficiently with a solution for a problem, 
and more information regarding the problem and solution will be provided to the 
service technician. Additionally, the quantifier values may become "predictive" of 
conditions that may soon cause a problem in the imaging devices 1 08. Thus, the 
service center 104 may respond before a problem manifests. 

[0059] The laboratory trial-and-error testing technique of the prior art is artificial, has 
limited resources, cannot adequately simulate real-world conditions and is not 
guaranteed to find every possible condition. The service center 104, on the other 
hand, benefits from having many devices within the enterprise facility 102 and from 
the random combination of events that occur naturally during normal operations. The 
service center 104 receives data spontaneously and in large numbers. Sounder data, 
better average results and a better chance of having the results relate to the real world 
are thus obtained. 
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